Traversal of symmetric network address translator for multiple simultaneous connections

ABSTRACT

Handling of multiple connections during NAT traversal for a node behind a symmetric NAT is disclosed. The likelihood of connection failure during symmetric NAT traversal may be reduced by serializing critical time windows after port prediction. Once a connection request has been sent for a first connection, port prediction for a subsequent connection may be delayed until a connectivity check has begun for the first connection. This process may be repeated to handle NAT traversal for multiple simultaneous connections to different nodes.

CLAIM OF PRIORITY

This Application claims the benefit of priority of commonly-assigned,co-pending U.S. patent application No. 12/043,080 to Yutaka Takeda,filed Mar. 5, 2008 and entitled TRAVERSAL OF SYMMETRIC NETWORK ADDRESSTRANSLATOR FOR MULTIPLE SIMULTANEOUS CONNECTIONS, the entire contents ofwhich are incorporated herein by reference.

FIELD OF THE INVENTION

Embodiments of this invention are related to computer networks and morespecifically to peer-to-peer communications across symmetric networkaddress translators on computer networks.

BACKGROUND OF THE INVENTION

The use of routers with a NAT (Network Address Translation) feature caninterfere in accessing an internal network from an external network.This can be a particular problem for peer-to-peer applications such asvoice communication over the Internet (known as VoIP) and/or onlinegaming, etc. NAT is an Internet standard that enables a local areanetwork (LAN) to use of one set of private IP addresses for internaltraffic and a second set of global IP addresses for external traffic. Anode that has NAT capability is often referred as “NAT box”.

A NAT (literally) translates network (IP) address between the twonetworks. Network Address Port Translation (NAPT) translates not only IPaddress but also port numbers of a transport layer protocol. AlthoughNAT/NAPT has its good properties, there is a significant side effect. Ifthe translation is performed dynamically, nodes in the external networkhave no way to know the IP address (and the port number) on the NATahead of time to reach a node in the internal network. Unfortunately,this is the most common behavior of NAT in the residential and SOHOrouters deployed in the current market.

A NAT can generally be categorized as being Full Cone, Restricted Cone,Port Restricted Cone or Symmetric. A full cone NAT maps all requestsfrom the same internal IP address and port to the same external IPaddress and port. Furthermore, any external host can send a packet tothe internal host through a full cone NAT by sending a packet to themapped external address. In a restricted cone NAT all requests from thesame internal IP address and port are mapped to the same external IPaddress and port. Unlike a full cone NAT, an external host with IPaddress X can send a packet to the internal host only if the internalhost had previously sent a packet to IP address X. A port restrictedcone NAT is like a restricted cone NAT, but the restriction alsoincludes port numbers. Specifically, an external host can send a packet,with source IP address X and source port P, to the internal host only ifthe internal host had previously sent a packet to IP address X and portP.

In a symmetric NAT all requests from the same internal IP address andport, to a specific destination IP address and port, are mapped to thesame external IP address and port. If the same host sends a packet withthe same source address and port, but to a different destination, adifferent mapping is used. Furthermore, only the external host thatreceives a packet can send a UDP packet back to the internal host. Thesymmetric NAT tends to be the most problematic type of NAT to traverse.One technique for symmetric NAT traversal is known as “port prediction”,which is described in detail in U.S. Patent Application publication20070076729A1, which is incorporated herein by reference. In this typeof symmetric NAT traversal, a first node is behind a first NAT that issymmetric and a second node that is behind a second NAT. The first nodeconstructs a list of predicted transport addresses on the first NAT andsends a message containing the list of predicted transport addresses tothe second node. A connectivity check is performed with the second nodeusing the predicted transport addresses.

It has been estimated that 18% of NATs are Symmetric and a connectionfailure rate of more than 10% is anticipated without port prediction.Some applications involving NAT traversal may require up to 64simultaneous connections. It is not clear whether port prediction canreliably work for such applications.

It is within this context that embodiments of the present inventionarise.

BRIEF DESCRIPTION OF THE DRAWINGS

The teachings of the present invention can be readily understood byconsidering the following detailed description in conjunction with theaccompanying drawings, in which:

FIGS. 1A-1B are message sequence diagrams illustrating NAT traversalusing port prediction.

FIG. 2 is a timing diagram illustrating modified port predictionaccording to an embodiment of the present invention.

FIG. 3 is a schematic diagram illustrating a system NAT traversalbetween two nodes according to an embodiment of the present invention.

FIG. 4 is a flow diagram illustrating a method of NAT traversal betweentwo nodes according to an embodiment of the present invention.

FIG. 5 is a schematic diagram of three nodes communicating over anetwork illustrating the problem of simultaneous prediction.

FIG. 6 is a schematic diagram of a node configured to implement portprediction according to an embodiment of the present invention.

DESCRIPTION OF THE SPECIFIC EMBODIMENTS

Although the following detailed description contains many specificdetails for the purposes of illustration, anyone of ordinary skill inthe art will appreciate that many variations and alterations to thefollowing details are within the scope of the invention. Accordingly,examples of embodiments of the invention described below are set forthwithout any loss of generality to, and without imposing limitationsupon, the claimed invention.

II. Summary

Port prediction technique is used to traverse symmetric NAT (NetworkAddress Translator). If a node behind a symmetric NAT is trying toconnect many remote nodes at a time, prediction could fail with a higherprobability. Embodiments of the invention avoid the connection failurecaused by the case of simultaneous port prediction by putting newrequests on hold until a previous request has reached a connectivitycheck stage. This allows a node multiple simultaneous connectionsthrough a symmetric NAT without causing problems with port prediction.

III. Terminology As used herein, the following terms have the meaningsshown in Table I below.

TABLE I natted node A node behind a NAT. client-server A networkarchitecture model where all clients connect to a central server. (ex.Web (HTTP) service, etc.) peer-to-peer A network architecture that doesnot depend on a central server. Each client (peer) directly connects toother peers. (ex. DHT, VoIP, file sharing system, etc.) transportaddress A set of IP address and port number. Voice over IP (VoIP) Atechnology enabling routing of conversations over the Internet or anyother IP network.

Acronyms

As used herein, the following acronyms have the meanings shown in TableII below.

TABLE II DHT Distributed Hash Table (ex. Chord) HTTP Hyper Text TransferProtocol IETF Internet Engineering Task Force LAN Local Area Network NATNetwork Address Translator (RFC 3022) NAPT Network Address PortTranslation (RFC 3022) SIP Session Initiation Protocol (RFC 3261) SSPSession Setup Protocol SOHO Small Office and Home Office STUN SessionTraversal Utility for NAT (previously known as “Simple Traversal of UDPthrough NAT”) TURN Traversal Using Relay NAT VoIP Voice over IP

IV. Problem Analysis

The basic problem of port prediction failure may be understood withrespect to FIG. 1A and FIG. 1B. FIG. 1A illustrates the basic flow ofNAT traversal when a first node 2 is behind a symmetric NAT (not shown).To initiate communication with a second node 4, the first node 2 sends abinding request 10 to a STUN server 6. In response, the STUN server 6sends back address information 12 from the symmetric NAT. Using theaddress information 12 and port prediction, the first node 2 canconstruct a list of candidate addresses including port numbers.

The first node A can send a connection request 14 with the list to nodeB via a signaling server 8. The second node 4 may also send a bindingrequest 16 to the STUN server 6 and receive address information 18 inresponse. Using the address information 18, the second node 4 maygenerate its own list of candidates and send the list in a provisionalresponse 20 to the first node 2. The first and second nodes may thenperform connectivity checks by sending check packets 22, 24.

It is noted that a critical time window T_(C1) exists for the first node2 between the sending of the binding request 10 and the sending of thefirst of the check packets 22. During this time port predictionperformed by the first node 2 is based on the address information 12sent by the STUN server 6 in response to the binding request 10. If thataddress information should change during this critical time, the portprediction may fail. The address information may change if the firstnode 2 initiates another binding request for communication with a thirdnode (not shown). A similar critical time window T_(C2) exists for thesecond node 4 between receipt of the connection request 14 from thefirst node 2 and the sending of the first check packets 24.

In general, the critical time window for NAT traversal ends when thefirst set of connectivity check packets are transmitted. Referring toFIG. 1A, the critical time window T_(C1) for the first node 2 ends whena first set of the check packets 22 are transmitted. The critical timewindow T_(C2) for the second node 4 ends when a first set of the checkpackets 24 are transmitted.

The Symmetric NAT traversal described with respect to FIG. 1A worksgenerally quite well for communication between one node and another. Anunanticipated problem may arise if a node attempts to make multiplesimultaneous connections to different nodes. Such situations may arise,e.g., in multi-player online gaming FIG. 1B illustrates the problem withmultiple communication sessions of a single application 30 running on anode behind a Symmetric NAT. By way of example, the application 30 mayinitiate a first session 32 in which the application attempts aconnection to Node A. The first session 32 negotiates the connectionstarting with a binding request and following receipt of a provisionalresponse begins connectivity checks. Suppose, however that during thecritical time window T_(C) the application 30 initiates a second session34 in which the application attempts to communicate with Node B. As partof the negotiation for the second session 34, a new NAT binding requestwill be sent to the STUN server. This changes port assignment on theNAT. Unfortunately, the first session 32 relies on a previous portassignment for port prediction for its communication with Node A. As aresult, port prediction for the first session 32 may fail and the firstsession will time out after some predetermined timeout period haselapsed. Although prior port prediction schemes were subject tonoticeable port prediction failures, the particular nature of theproblem, as described above, was not generally recognized.

IV. Solution

Embodiments of the present invention overcome problems with multipleport predictions by serializing “critical windows” during thenegotiation phase of NAT traversal, while establishing many connectionsat a time. It is noted that certain applications, such as multi-playeronline game applications can support the establishment of multiplepeer-to-peer connections.

According to an embodiment of the present invention, serialization ofthe critical time window may be implemented on a node behind a symmetricNAT that attempts to initiate peer-to-peer connections over a networkwith two or more other nodes. In particular, the first node may performa port prediction for initiating a communication session with a secondnode with first node and construct a list of predicted transportaddresses on the symmetric NAT and then send a CONNECTION REQUESTmessage containing the list of predicted transport addresses to thesecond node. Upon receipt of a provisional response to the CONNECTIONREQUEST message. The first node may then perform a check of connectivitybetween the first node and the second node using the predicted transportaddresses, e.g., by sending test packets. The first node may serializethe critical time window by delaying port prediction for communicationbetween the first node and a third node until after the connectivitycheck has begun.

In a similar fashion, serialization of the critical time window may beimplemented on a node behind a symmetric NAT that receives a CONNECTIONREQUEST to initiate a peer-to-peer connection over a network whilenegotiating NAT traversal with one or more other nodes. When such a nodereceives a CONNECTION REQUEST message from another node it may performport prediction and send a provisional response to the CONNECTIONREQUEST message with a list of predicted addresses and perform a checkof connectivity. Port prediction for communication with an additionalnode may be delayed until after the connectivity check has begun.

Specifically, as shown in the timing diagram of FIG. 2, the first node 2may originate or receive N connection requests R₁, R₂, . . . R_(N) atthe same time. The first request R₁ may be processed as described abovewith respect to FIG. 1A. Subsequent requests R₂ . . . R_(N), however arequeued in a serial fashion in the order in which they were generated orreceived. Specifically, each of the subsequent requests waits until thecritical time window T_(C) for each previous request has passed beforebeginning port prediction.

As discussed above, a connection may fail if it cannot be establishedwithin a timeout period T_(O). Consequently, it is desirable that thetimeout period T_(O) is sufficiently long that all N connections can beestablished. By way of example, assuming that all of the critical timewindows T_(C) for each connection are of some be less than some maximumnumber of connections the timeout period T_(O) should be less thanN_(max)T_(C)+T_(conn), where T_(conn) is the time for the connectivitycheck and N_(max) is some maximum number of possible simultaneousconnections.

As shown in FIG. 3, a first node 102 resides in a first private networkNW1 that is physically connected to a public network PNW (e.g., theinternet) via a first NAT 103. Similarly, second node 104 resides in asecond private network NW2 and is able to access the same public networkvia a second NAT 105. The private networks NW1 and NW2 may each includeother nodes and other NATs in addition to the first and second nodes102, 104 and the first and second NATs 103, 105. Other private networksmay also be connected to the public network PNW. The pubic network PNWincludes an SIP proxy server 100, and a STUN server 101. The first node102 has a private IP address that is valid only in the first privatenetwork NW1 behind the first NAT 103. The first node 102 has a globallyunique and routable IP address, and the first NAT 103 performs IPaddress and port translation between the public network and the privatenetwork. Similarly, the second node 104 has a private IP address that isvalid only in the second private network NW2 behind the second NAT 105.The second node 104 has a globally unique and routable IP address, andthe second NAT 105 performs IP address and port translation betweenpubic network and the private network.

The nodes 102, 104 can be, e.g., server hosts such as audio/video (A/V)chat, multimedia streaming devices, file sharing nodes, online gamingmodules etc. Each node 102, 104 may be a general purpose computer thatbecomes a special purpose computer when running instructions, such asinstructions for implementing the steps of the method of FIG. 6. By wayof example, the nodes 102 and 104 may be SIP user agents and able tosend and receive messages each other through a SIP proxy server 100. Thenodes 102 and 104 are also STUN clients. Thus, the first node 102 isable to discover the presence and types of NAT in the path between thefirst node 102 and the STUN server 101 by a communication with the STUNserver 101 using STUN protocol. The second node 104 is similarly able todiscover the presence and types of NAT between the second node 104 andthe STUN server 101.

A method of NAT traversal according to embodiments of the presentinvention may be understood by simultaneously referring to the blockdiagram of FIG. 3 and flow diagram of FIG. 4. Initially, each node 102,104 may perform NAT discovery using STUN protocol as indicated at 202,204 of FIG. 4. In the example illustrated, the first node 102 discoversthat it is behind the first NAT 103 and its type is Symmetric. Thesecond node 104 discovers that it is also behind the second NAT 105 andits type is, e.g., Port restricted-cone. Then, both nodes 102, 104 mayregister themselves to the SIP proxy server 100 to join a network asindicated at 206, 208. This establishes first and second signaling paths116, 117 to the SIP proxy server 100. Once established, the SIP proxyserver 100 can forward messages to the first and second nodes 102, 104respectively through the first and second signaling paths 116, 117.

By way of example, the first node 102 may wish to establish apeer-to-peer connection to the second node 104. The first node 102allocates a local port 107 for the new peer-to-peer session. Then thefirst node 102 obtains an external port 112 by sending a binding request118 from the local port 107 to the STUN server 101. The sending of thebinding request begins the critical time window for the first node 102.Since the first node 102 knows that the first NAT 103 is present and isof type Symmetric, it may perform port prediction as indicated at 210and construct a list of transport addresses 107, 110, 112, 113 and 114.The list may be put into a new CONNECTION REQUEST message. In apreferred embodiment, the first node 102 may send no information aboutthe first NAT 103. Furthermore, the first node 102, not the second node104, may perform the port prediction. In addition, sending CONNECTIONREQUEST messages containing transport addresses is perfectly compatiblewith the existing ICE methodology.

To prevent a subsequent binding request for connection to another nodefrom interfering with port prediction, the first node 102 may begin await period upon sending the binding request 118 as indicated at 209.During the wait period, new binding requests for communication withother nodes may be temporarily put on hold and queued in the order inwhich they originated.

At step 212, the first node 102 sends the CONNECTION REQUEST messagewith the list of transport addresses to a SIP proxy server 100 throughthe already established path 116. The SIP proxy server 100 finds in themessage that the final destination is the second node 104 and forwardsthe CONNECTION REQUEST message through the already establish path 117,and port 111 and finally the message reaches the second node 104 onlocal port 108. On reception of the CONNECTION REQUEST, the second node104 may allocate a local port 109 for the future peer-to-peer session,and then the second node 104 may obtain an external port 115 by sendinga binding request 119 from the local port 109 to the STUN server 101. Toprevent a subsequent binding request for connection to another node frominterfering with port prediction, the second node 104 may begin a waitperiod upon receiving the CONNECTION REQUEST message as indicated at211. During the wait period, the second node 104 may temporarily put newbinding requests for communication with other nodes on hold and queuethem in the order in which they originated. Specifically, Node 1 102 mayput a request 217 from Node X 125 in a queue in the order in which therequest was received. Node 2 104 may similarly queue a request 219 fromnode Y 127.

Since the second node 104 knows that the second NAT 105 is notSymmetric, it puts the local port 109 and the external port 115 in a newprovisional response message and sends it back to the first node 102 at214 via the SIP proxy server 100 and the first and second signalingpaths 117, 116. The transmission of the provisional response terminatesthe transport exchange phase and starts connectivity check phase. Atthis stage, the first and second nodes 102, 104 may safely initiate newbinding requests for communication with other nodes. Consequently, thewait period for the first and second nodes 102, 104 may end, asindicated at 213, 215 respectively

To check connectivity, both nodes 102 and 104 may start sending STUNpackets from their local ports 107, 109 to check connectivity to thetransport addresses obtained from the other node at steps 216, 218. Whenthe first node 102 sends a STUN packet 120, the first NAT 103 allocatesa new external port 113, and then the packet 120 reaches the externalport 115 on the second NAT 105. The first few packets could be discardedat the external port 115 because the second NAT 105 is a port restrictedcone NAT and the second node 104 might not yet have sent a packet fromthe local port 109 to the external port 113 on the first NAT 103. Thesecond node 104 also sends STUN packets 121, 122, 123 to the obtainedtransport addresses 112, 113 and 114. The packet 121 reached at the port112 is discarded because the first NAT 103 is a Symmetric NAT and theport 112 is exclusively allocated for the session to the STUN server101. The STUN packet 123 reached at 114 is also discarded because thereis no such external port allocated by the first NAT 103. The STUN packet122 reached at 113 is forwarded by the first NAT 103 to the local port107. The first node 102 then sends a response to the second node 104 andthe second node 104 finds it has connectivity to the port 113 on thereception of the response. The STUN packet sent from the local port 107on the first node 102 to the external port 115 on the second NAT 105 iseventually received at the local port 109 of second node 104. The secondnode 104 then sends a response back to the first node 102.

Upon reception of the response message, at step 220 the first node 102sends an UPDATE message to the second node 104 via the SIP proxy server100 to tell the second node 104 that the first node 102 foundconnectivity to the external port 115. This triggers the second node 104to send a final response message to the first node 102 at step 222 tofinalize the connection establishment process.

Instead of putting a NAT type in the message and having the second node104 to make a prediction, the first node 102 makes a prediction and putsthe predicted external ports 113, 114 along with the external port 112obtained from STUN server 101, in the new CONNECTION REQUEST message.Thus, the first node 102 provides no information about the first NAT 103to the second node 104. Such use of ICE method completely eliminatescomplicated NAT combination logic for “break-out” packets as done in theprior art (U.S. 2004/0139228). Instead, embodiments of the presentinvention can achieve the same result by performing a connectivity checkthat is essentially equivalent to the “break-out packet”. Thus,embodiments of the invention allow a system that already uses ICEmethodology to add Symmetric NAT traversal capability by simply addingthe predicted transport addresses to the connectivity check list.

As described above, the first node 102, i.e., the node attempting toinitiate communication with the second node 104 performs a portprediction and puts the predicted ports in the CONNECTION REQUESTmessage. There are a number of techniques of performing the portprediction. For example, port prediction may be implemented using a portallocation rule discovery process using the following test. The firstnode 102 sends a STUN binding request to the STUN server 101 without anyflags set in the CHANGE-REQUEST attribute and without theRESPONSE-ADDRESS attribute. This causes the STUN server 101 to sendresponses back to the address and port that the request came from. Thistest is applied to different combinations of IP addresses and ports inorder to figure out the port allocation characteristics of the NAT 103.The STUN server 101 uses two different IP addresses, C_(A) and D_(A) andtwo different ports C_(P) and D_(P) as shown in Table III below.

TABLE III DESTINATTION IP ADDRESS PORT TRY-1 D_(A) D_(P) TRY-2 D_(A)C_(P) TRY-3 C_(A) D_(P) TRY-4 C_(A) C_(P)

As can be seen from Table III, the test is performed four times (e.g.,from TRY-1 to TRY-4) per local port in this example. All the tests mustbe done from the same local port. The first node 102 obtains four mappedaddresses from the responses. These four mapped addresses are analyzedto determine the port allocation rule and a port increment value ΔP andto evaluation consistency. To look for consistency, the process can beperformed multiple times, preferably using a different local port thatdoes not have a NAT binding associated with it. The port allocation rulecan be determined by looking at the port numbers obtained from themapped addresses. If all port numbers are incremented for successivedestinations having different port numbers, the port allocation rule issaid to be “port sensitive”. If the port increment size from successivedestinations having the same IP address (e.g., from TRY-1 to TRY-2 andfrom TRY-3 to TRY-4) is always zero, but the incremental size fromsuccessive destinations having different IP addresses (e.g., TRY-2 toTRY-3) is not zero, the port allocation rule is said to be “addresssensitive”. If all port numbers of the obtained mapped addresses are thesame, the NAT 103 is a ‘Cone NAT’.

The ΔP value may be determined as follows. For address sensitiveallocation, the ΔP value is equal to a port increment size betweensuccessive tries for which the destination port is different, e.g., forTRY-2 and TRY-3. The process may be repeated from another local port asshown in Table IV. In this example, TRY-1 through TRY-4 are as in TABLEIII and TRY-5-TRY 8 continue the pattern destination IP addresses andport numbers of Table III.

TABLE IV TRY MAPPED ADDRESS ΔP 1 67.105.12.10:49152 2 67.105.12.10:491520 3 67.105.12.10:49154 2 4 67.105.12.10:49154 0 5 67.105.12.10:49156 2 667.105.12.10:49156 0 7 67.105.12.10:49158 2 8 67.105.12.10:49158 0

Note that from Table IV it can be seen that where the destination IPaddress is the same for successive tries, the port numbers in thecorresponding mapped addresses are the same. From this it can bedetermined that the port allocation rule is “address sensitive”.Furthermore it can be seen that the value of AP is equal to the portincrement between TRY-2 and TRY-3 and is also equal to the portincrement sizes between TRY-4 and TRY-5 and between TRY-6 and TRY-7.

For port sensitive allocation, the value of ΔP is the difference betweenadjoining port numbers of mapped addresses obtained from testingTRY-[N+1] and TRY-[N]. In situations where the first node 102 cannotfind consistency in the port increment size for ΔP determination, theapplication may include an algorithm to determine the ΔP value based onstatistical observation, or to decide to give up obtaining a valid ΔP.

If the second NAT 105 is not symmetric, it may be sufficient to performport prediction, e.g., as part of the NAT discovery step 202 for thejust the first node 102. In the case where the second NAT 105 is also aSymmetric NAT, the second node 104 may perform similar port predictionas part of its NAT discovery phase 204.

It is noted that in embodiments of the invention, a node may beconfigured to serialize the critical time windows for NAT traversal maybe serialized for multiple connections to other nodes. Serializing thecritical time windows as described above may potentially give rise to apossible pitfall referred to herein as a Symmetric Node Connection Loop.It is noted that queuing connection requests to serialize the criticaltime windows is not generally necessary for a node that is not behind asymmetric NAT. However, a lockup may occur if critical time windowserialization is implemented for three or more nodes, each of which isbehind a symmetric NAT. The nature of this pitfall may be appreciatedwith reference to FIG. 5 in which three nodes A, B and C are all behindsymmetric NATs. If Node A tries to contact node B while Node B is tryingto contact Node A an initiation dependency loop may be created among thethree nodes that could result in a lockup in which none of the nodes cansuccessfully initiate peer-to-peer communication.

In the example depicted in FIG. 5, if all three nodes are configured toimplement serialized critical time windows, e.g., as discussed abovewith respect to FIG. 2, Node A may wait for Node B to initiate with NodeC while Node B waits for Node C to initiate with A and Node C waits forNode A to initiate with Node B. In such a situation, all three Nodes maybe waiting at the same time, which creates the lockup situation. Toovercome this problem, an initiate-transaction timeout may beimplemented.

By way of example, Node C could send a “QUEUED” message Q to Node B. TheQUEUED message Q indicates that Node C is behind Symmetric NAT and iswaiting for a connection to another node. Node B could wait for apredetermined wait time T_(W), then cancel its initiation with Node Cand then subsequently initiate again with C after processing theconnection request from Node A. The wait time T_(W) may be greater thanor equal to zero and less than a timeout time that Node B wouldordinarily wait before giving up on communication with Node C. A littlemore specifically, C sends the “QUEUED” message Q to B because C knowsthat C is behind a symmetric NAT and the request was not processed rightaway but was queued. Node B could wait a relatively shorter time period(e.g. 3 seconds) in response to the “QUEUED” message, then cancel(putoff) the connection process to Node C, process other requests in thequeue, then eventually initiate again with C. To prevent Node B fromretrying to initiate with Node C indefinitely, the number of retries tothe same node may be limited, e.g., up to 3 times, after which, Node Bcould completely give up. The application running on Node B wouldreceive a connect error in such a case.

As an alternative solution to the lockup, the technique described abovemay be modified in the following way. The critical time windows may beserialized for outgoing connection requests only and slightly deeperport predictions may be performed. For example, instead of generating aport prediction based on the port increment ΔP, additional portpredictions may be generated based on 2ΔP, 3ΔP . . . MΔP, where M is aninteger referred to herein as the “depth” of the prediction. By way ofexample, suppose it is determined that for a particular symmetric NATthe port increment ΔP=1. A candidate list based on a port prediction ofdepth M=1 based on this value of ΔP may look like this:

-   -   Candidate 1: type=stun, 202.10.9.20:9021 (predicted)    -   Candidate 2: type=local, 192.168.1.2:3658

Deepening the prediction from M=1 to M=3 may produce the followingcandidate list:

-   -   Candidate 1: type=stun, 202.10.9.20:9021 (predicted)    -   Candidate 2: type=stun, 202.10.9.20:9022 (predicted)    -   Candidate 3: type=stun, 202.10.9.20:9023 (predicted)    -   Candidate 2: type=local, 192.168.1.2:3658

Unlike the use of the “QUEUED” signaling message, the foregoing solutionmay not address every possible lockup situation, but it may be simplerto implement. Furthermore, since connection processes more likely occurin parallel at calling side, serializing the outgoing connections, butnot the incoming connections can avoid the most likely lockupsituations. Since the critical time windows for incoming connections arenot serialized, port prediction may fail. Increasing the depth of theport prediction, e.g., from M=+1 to M=+3 increases the number ofpredicted candidates, which decreases the likelihood of port predictionfailure.

The examples illustrated below with FIG. 3 and FIG. 4 pertains to apeer-to-peer UDP session establishment using SIP (Session InitiationProtocol; RFC 3261) protocol. Embodiments of the invention, however, areapplicable to any other signaling protocols that allow a peer to sendand receive signals to another peer via a proxy server on the pubicnetwork prior to a peer-to-peer direct connection establishment. Suchsignaling protocols may include but are not limited to H.323, MGCP,HTTP, XMPP, etc.

The NAT traversal algorithm may be implemented in software or hardwareor a combination of both. By way of example, FIG. 6 depicts a computerapparatus 400 for implementing such an algorithm. The apparatus 400 mayinclude a processor module 401 and a memory 402. The processor module401 may include a single processor or multiple processors. As an exampleof a single processor, the processor module 401 may include a Pentium®microprocessor from Intel or similar Intel-compatible microprocessor. Asan example of a multiple processor module, the processor module 401 mayinclude a cell processor.

The memory 402 may be in the form of an integrated circuit, e.g., RAM,DRAM, ROM, and the like). The memory 402 may also be a main memory or alocal store of a synergistic processor element of a cell processor. Acomputer program 403 that includes the frame reconstruction algorithmdescribed above may be stored in the memory 402 in the form of processorreadable instructions that can be executed on the processor module 401.The processor module 401 may include one or more registers 405 intowhich instructions from the program 403. The instructions of the program403 may include the steps of the method for peer to peer connection overa network, e.g., as described above with respect to FIG. 2, FIG. 3 andFIG. 4. Specifically, the program 403 may queue requests for connectionto other nodes as described above to prevent multiple connectionattempts from interfering with port prediction. The program may generatea connection queue 407 that is stored in memory 402. The connectionqueue 407 may be implemented as a table or other data structure. Theconnection queue 407 may store the time that a particular connection wasinitiated so that connections may be released from the queue 407 afterthe critical time window for another previously initiated queue haspassed.

The program 403 may be written in any suitable processor readablelanguage, e.g., C, C++, JAVA, Assembly, MATLAB, FORTRAN and a number ofother languages. The apparatus may also include well-known supportfunctions 410, such as input/output (I/O) elements 411, power supplies(P/S) 412, a clock (CLK) 413 and cache 414. The apparatus 400 mayoptionally include a mass storage device 415 such as a disk drive,CD-ROM drive, tape drive, or the like to store programs and/or data. Theapparatus 400 may also optionally include a display unit 416 and userinterface unit to facilitate interaction between the device and a user.The display unit 416 may be in the form of a cathode ray tube (CRT) orflat panel screen that displays text, numerals, graphical symbols orimages. The display unit 416 may also include a speaker or other audiotransducer that produces audible sounds. The user interface 418 mayinclude a keyboard, mouse, joystick, light pen, microphone, or otherdevice that may be used in conjunction with a graphical user interface(GUI). The apparatus 400 may also include a network interface 420 toenable the device to communicate with other devices over a network, suchas the internet. These components may be implemented in hardware,software or firmware or some combination of two or more of these.

V. Results

An embodiment of the invention was tested with a peer-to-peer librarythat implements NAT traversal features, using a simple connectivitycheck tool running on top of the peer-to-peer library. Nodes at bothends of the connection were behind Symmetric NATs. A peer-to-peerlibrary node implemented on a PlayStation 3 development stationattempted to connect to 64 other nodes running on a Linux PC. Criticaltime windows for both outbound and inbound connections were serialized.All 64 connections successfully established.

While the above is a complete description of the preferred embodiment ofthe present invention, it is possible to use various alternatives,modifications and equivalents. Therefore, the scope of the presentinvention should be determined not with reference to the abovedescription but should, instead, be determined with reference to theappended claims, along with their full scope of equivalents. Any featuredescribed herein, whether preferred or not, may be combined with anyother feature described herein, whether preferred or not. In the claimsthat follow, the indefinite article “A”, or “An” refers to a quantity ofone or more of the item following the article, except where expresslystated otherwise. The appended claims are not to be interpreted asincluding means-plus-function limitations, unless such a limitation isexplicitly recited in a given claim using the phrase “means for.”

1. A method for peer-to-peer connection over a network between a firstnode behind a first symmetric network address translator (NAT) and twoor more other nodes, the method comprising: a) sending a connectionrequest message containing the list of predicted transport addressesfrom the first node to a second node; b) receiving a provisionalresponse to the connection request message at the first node; c)performing a check of connectivity between the first node and the secondnode using the predicted transport addresses; and d) delaying portprediction for communication between the first node and a third nodeuntil after d) has begun.
 2. The method of claim 1, further comprising:e) after d), performing the port prediction for communication betweenthe first node and a third node, wherein the first node constructs alist of predicted transport addresses on the first NAT; f) sending aconnection request message containing the list of predicted transportaddresses from the first node to a third node; g) performing a check ofconnectivity between the first node and the third node using thepredicted transport addresses.
 3. The method of claim 2, furthercomprising: h) delaying port prediction for communication between thefirst node and a fourth node until after g).
 4. The method of claim 1wherein performing the connectivity check includes sending SessionTraversal Utility for NAT (STUN) packets from the second node to the oneor more transport addresses provided by the first node in the connectionrequest message.
 5. The method of claim 4 wherein performing theconnectivity check further includes sending a STUN packet response fromthe first node to the second node, wherein the STUN packet responseincludes a transport address of an external port on the first NATthrough which one of the STUN packets sent from the second node reachedthe first node.
 6. The method of claim 1, further comprising: waitingfor a period of time T_(W) after a), but before b) in response to amessage from the second node indicating that the second node is queuedfor connection to another node; canceling the communication sessionbetween the first node and the second node; and repeating a), b), c),d), wherein the amount of time T_(W) is greater than or equal to zeroand less than a timeout for connectivity failure between the first andsecond nodes.
 7. The method of claim 1, wherein c) includes sending oneor more test packets from the first node to the second node using atransport address from the list of predicted transport addresses.
 8. Themethod of claim 10 wherein d) includes delaying port prediction forcommunication between the first node and the third node until after afirst of the one or more test packets has been sent.
 9. A node,comprising: a processor; a memory; a network interface; and instructionsembodied in the memory and configured for execution on the processor,the instructions comprising: a set of instructions that, when executed,cause the node to: i) send a connection request message containing thelist of predicted transport addresses from the node to a second node;ii) receiving a provisional response to the connection request messageat the node; iii) performing a check of connectivity between the firstnode and the second node using the predicted transport addresses; andiv) delaying port prediction for communication between the node and athird node until after iii) has begun.